Software to be executed on an electronic device may be digitally signed to confirm the origin/author of the software, guarantee the integrity of the software (for example, guarantee that the software has not be altered or corrupted), and/or ensure that the software is approved for execution on the electronic device. Many code signing implementations allow the software to be digitally signed with a private key and verified with a corresponding public key. A developer or entity releasing software may use a unique private key assigned to the developer or entity to digitally sign the software after it is created. Before the software can be executed on an electronic device, the electronic device attempts to verify the signature using the public key corresponding to the unique private key, the public key (or some representation of the public key, such as the cryptographic hash of the public key) being embedded into the electronic device, such that it becomes an unalterable, trust anchor. If the electronic device can verify the digital signature, the device may execute the software. If, on the other hand, the electronic device cannot verify the signature, the device may not execute the software. This code signing implementation therefore enhances software security and prevents the electronic device from being hacked (broken) into and loaded with unauthorized software without this unauthorized software being detected the next time the device checks the signature of this software.
While security may be enhanced by such a code signing implementation, in a development environment, software developers may need to load and execute newly created software on one or more devices. To ensure that software created in the development environment can be executed on one or more devices, all developers in this environment may be allowed to digitally sign software such that, once signed, this software can be executed on a set of devices. However, this approach may weaken the software security. Consider for example that when each developer in a group is allowed to digitally sign and operate software on the set of devices, any of the developers may maliciously sign the software, leaving the set of devices vulnerable to execute unauthorized code.
As an alternative, a select group (referred to herein as a release authority) may be authorized to digitally sign software with a private release key, wherein software signed with the private release key may be executed on the set of devices. Rather than providing each developer with access to the private release key, each developer may be provided access to a private developer key, wherein software signed with the private developer key may be executed on only one device. Each developer's digital signature will be over the software and may also be over a device identifier associated with an electronic device on which the software is to be executed. This restricts execution of the developer-signed software to one electronic device. Accordingly, before the developer-signed software can be executed on a device, an authentication routine on the device ensures that the device identifier in the digital signature matches a unique device identifier associated with the device.
This code signing implementation may be inconvenient in the development phase. Consider an example where software being developed must be tested on multiple devices, wherein a first developer builds the software and sends it to a second developer to be tested. In order to test the software on more than one device, the first developer must obtain the unique device identifier associated with each device on which the software is to be tested, must include the unique device identifier for each device when calculating the digital signature using the developer private key, and send the signed software for each device to the second developer. The process of individually signing the software for each device may be time-consuming and inconvenient for the first developer. In addition, the second developer must ensure that the appropriate software is installed on each device, i.e., the second developer must ensure that the developer-signed software with the unique device identifier for the first device is installed on the first device; the developer-signed software with the unique device identifier for the second device is installed on the second device; and so on. If the second developer does not appropriately match the developer-signed software with the appropriate device, the software will not be executed on the device because the device identifier in the developer-signed software will not match the unique device identifier associated with the device. In addition to being error-prone, the process of individually matching the developer-signed software to the appropriate device and installing the correctly-signed software on each device may also be time-consuming and inconvenient for the second developer.
Accordingly, there is a need for a method and apparatus for enabling multi-state code signing without compromising security.
Skilled artisans will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions of some of the elements in the figures may be exaggerated relative to other elements to help to improve understanding of embodiments of the present invention.
The apparatus and method components have been represented where appropriate by conventional symbols in the drawings, showing only those specific details that are pertinent to understanding the embodiments of the present invention so as not to obscure the disclosure with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein.